APPLICATION 



FOR 



UNITED STATES LETTERS PATENT 



APPLICANT NAME T. A. ABER, ET AL 



TITLE 



SYSTEM AND METHOD FOR INVOICE 
IMAGING THROUGH NEGATIVE 
CONFIRMATION PROCESS 



DOCKET NO. 



END9 2000 0175 US1 



INTERNATIONAL BUSINESS MACHINES CORPORATION 



CERTIFICATE OF MAILING UNDER 37 CFR 1.10 

I hereby certify that, on the date shown below, this correspondence is being 
deposited with the United States Postal Service in an envelope addressed to 
the Commissioner of Patents and Trademarks, Washington, D.C., 20231 as 

"Express Mail Post Office to Addressee" on 03/22/01 

Mailing Label No. EL598672982US 
Name of person mailing paper: Christine Lang 

Signature //^ Date 7 / 



i:formal2.hvp 



SYSTEM AND METHOD FOR INVOICE IMAGING THROUGH NEGATIVE 

CONFIRMATION PROCESS 

Background of the Invention 

Cross References to Related Applications 

The following U.S. patent applications, filed 
concurrently or otherwise copending, are assigned to the 
assignee hereof and contain subject matter related, in 
certain respect, to the subject matter of the present 
application. 

Serial No. 09/657, 215, filed 7 Sep 2000, entitled "System and 
Method for Clustering Servers for Performance and Load 
Balancing", assignee docket END9-2000-0104-US1 ; 

Serial No. 09/657,216, filed 7 Sep 2000, entitled "System 
and Method for Front End Business Logic and Validation", 
assignee docket END9-2000-0105-US1 ; 

Serial No. 09/657,217, filed 7 Sep 2000, entitled "System 
and Method for Data Transfer With Respect to External 
Applications", assignee docket END9-2000-0106-US1 ; 
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Serial No. 09/656,037, filed 7 Sep 2000, entitled "System 
and Method for Providing a Relational Database Backend", 
assignee docket END9-2000-0107-US1; 

Serial No. 09/656,803, filed 7 Sep 2000, entitled "System 
and Method for Providing a Role Table GUI via Company 
Group", assignee docket END9-2000-0108-US1 ; 

Serial No. 09/656,967, filed 7 Sep 2000, entitled "System 
and Method for Populating HTML Forms Using Relational 
Database Agents", assignee docket END9-2000-0109-US1; 

Serial No. 09/657,196, filed 7 Sep 2000, entitled "System 
and Method for Catalog Administration Using Supplier 
Provided Flat Files", assignee docket END9-2000-0110-US1 ; 
and 

Serial No. 09/657,195, filed 7 Sep 2000, entitled "System 
and Method for Providing an Application Navigator Client 
Menu Side Bar", assignee docket END9-2000-0111-US1 . 

Serial No. 09/ , entitled "SYSTEM AND METHOD FOR 

AUTOMATING INVOICE PROCESSING WITH POSITIVE CONFIRMATION", 
assignee docket number END 9 2000 0165 US1 . 
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Serial No. 09/ , entitled "SYSTEM AND METHOD FOR 

GENERATING A COMPANY GROUP USER PROFILE", assignee docket 
number END9 2000 0166 US1. 

Serial No. 09/ , entitled "SYSTEM AND METHOD FOR 

SHARING DATA ACROSS FRAMES USING ENVIRONMENT VARIABLES 
assignee docket number END 9 2000 0167 US1. 

Serial No. 09/ , entitled "SYSTEM AND METHOD FOR 

SYNCHRONIZING LEDGER ACCOUNTS BY COMPANY GROUP", assignee 
docket number END 9 2000 0168 US1. 

Serial No. 09/ , entitled "SYSTEM AND METHOD FOR 

GROUPING COMPANIES ACCORDING TO ACCOUNTING SYSTEM OR RULES", 
assignee docket number END 9 2000 0169 US1. 

Serial No. 09/ , entitled "SYSTEM AND METHOD FOR FRAME 

STORAGE OF EXECUTABLE CODE", assignee docket number END 9 
2000 0174 US1. 

Serial No. 09/ , entitled "SYSTEM AND METHOD FOR 

LEVERAGING PROCUREMENT ACROSS COMPANIES AND COMPANY GROUPS", 
assignee docket number END 9 2000 0176 US1. 
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Serial No. 09/ , entitled "SYSTEM AND METHOD FOR 

PROCESSING TAX CODES BY COMPANY GROUP", assignee docket 
number END 9 2000 0177 US1. 

Serial No. 09/ , filed 2 March 2001, entitled "SYSTEM 

AND METHOD FOR MANAGING INTERNET TRADING NETWORKS", assignee 
docket number END9 2000 0178 US1. 

The above-identified patent applications are incorporated 
herein by reference. 

Technical Field of the Invention 

This invention pertains to invoice processing. More 
particularly, it relates to a system and method for 
capturing and rendering invoices viewable on the web. 

Background Art 

Historically, payments of invoices are triggered by a 
three way match: the invoice must match the purchase order 
(PO) terms and conditions, and the goods received must match 
those stated in quality and quantity against that PO. A 
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problem occurs, particularly with respect to general 
procurement items, when such items are not tangible things 
which come through a receiving dock. In this case, it is 
difficult to do the three way match. For example, services 
may not flow through a dock. As a result, procurement 
systems have defined an "invoice not received" situation, 
which results in payment not being made until someone does 
something — and that initiates what is referred to as a 
paper chase. 

Some procurement systems implement a "negative 
confirmation" process which results in payment of an invoice 
unless a requester submits a rejection. In this process, 
when an invoice is received, a notification is given to the 
requester alerting him to fact that the invoice will be paid 
unless requester sends back a notification that it should 
not be paid. 

Invoices may be received via mail (paper invoices) or 
electronically (EDI, as IDOC invoices) . In a negative 
confirmation system, it is important that invoice data be 
provided to a customer requester, and this has, in the case 
of paper invoices, resulted in the need to transfer paper 
copies, and in the case of electronic invoices, paper 
END 9 2000 0175 US1 5 



printouts or electronic summaries- In the case of paper 
copies, this involves the handling of large amounts of paper 
with the possibility of loss or delay adversely impacting 
the negative confirmation process, and in the case of 
electronic ' summaries providing information which may not be 
complete and sufficiently clear for quick human processing. 

Another problem with negative authorization is that, 
while it may work fine for low cost things, for larger (more 
expensive) things, the risk that payment will be made before 
negative confirmation could be received may be too great. 

It is an object of the invention to provide an improved 
system and method for processing invoices. 

It is a further object of the invention to provide a 
system and method for processing invoices according to 
either a positive or negative approval process. 

It is a further object of the invention to provide a 
system and method for processing both electronic and paper 
invoices by either a positive or negative approval process 
and with electronic capture and storage of all invoices for 
viewing by a customer approver. 
. END 9 2000 0175 US1 6 



Summary of the Invention 



A system and method for processing invoices, the method 
including the of- preparing of an invoice image; storing 
the invoice image in an image store; keying said image to 
invoice data; communicating invoice confirmation request to 
an approver, the request including invoice data and a link 
to the invoice image; and responsive to approver selection 
of the link, displaying the invoice image. 

In accordance with an aspect of the invention, there is 
provided a computer program product configured to be 
operable for processing invoices. 

Other features and advantages of this invention will 
become apparent from the following detailed description of 
the presently preferred embodiment of the invention, taken 
in conjunction with the accompanying drawings. 
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Brief Description of the Drawings 



Figure 1 is a high level system diagram illustrating an 
enterprise system for providing procurement services with 
respect to a plurality of vendors on behalf of a plurality 
of company groups of related customer companies in 
accordance with the preferred embodiment of the invention. 

Figure 2 is a high level system diagram illustrating 
the LPN application architecture of the preferred embodiment 
of the invention. 

Figure 3 is a diagram illustrating the inputs and 
outputs of the customer requisition catalog (RCW) component 
of the architecture of Figure 2. 

Figure 4 is a diagram illustrating, inter alia, the 
inputs and outputs of the enterprise EDI translator 44 of 
the architecture of Figure 2. 

Figure 5 is a diagram illustrating the inputs and 
outputs of the enterprise procurement system 42 of the 
architecture of Figure 2. 
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Figure 6 is a diagram illustrating the inputs and 
outputs of the enterprise procurement hub server of the 
architecture of Figure 2. 

Figure 7 is a diagram illustrating the system and 
method of the invention for capturing and rendering invoices 
viewable on the web in accordance with the preferred 
embodiment of the invention. 

Figures 8-12 represent a series of screen captures 
illustrating the user interface for requester processing of 
invoice confirmations. 

Best Mode for Carrying Out the Invention 

Referring to Figure 1, the procurement services 
organization of an enterprise 244 provides procurement 
services to a plurality of companies 248, 249 organized in a 
plurality of company groups 241-243 with respect to a 
plurality of vendors 245-247. 

Referring to Figure 2, the architecture of system 
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components administered by enterprise 244 includes a 
customer requisition and catalog (ReqCatWeb, or RCW) system 
40, an enterprise procurement system (SAP) 42, an enterprise 
data interchange, or EDI translator system 44, an enterprise 
(LPN) hosted data warehouse 50, an enterprise procurement 
hub server 52, Also illustrated in Figure 2 are a customer 
requester web terminal 46 and vendors 48. 

ReqCatWeb 40 is a front-end interface between the user 
and the procurement system, providing access to catalogs and 
commodities, to order the day-to-day items required for the 
business . 

SAP 42 is the back-end purchasing engine of the 
enterprise, such as is supported by IBM, accepting the 
requisitions from the front-end ReqCatWeb 40, and generating 
EDI transactions, as well as the accounting transactions for 
the requisitions, etc. 

EDI (Electronic Data Interchange) 44 is an application 
that interacts with suppliers by sending standardized 
transactions for purchase orders, receiving invoices, etc. 



LPN Hosted DataWarehouse 50 is a data-warehouse 
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facility for storing all transactions that occur in the 
system; used as a tool for monitoring transactions and 
gathering statistics. 

Hub Server 52 is a back-end processing server for 
transferring data between elements (that is, servers) of the 
system. 

Customer ERP System 54 is a back-end purchasing system 
as supported by the customer. 

Referring to Figure 3, the inputs to customer RCW 
system 40 from procurement system 42 include requisition 
status 41, purchase order (PO) status and contracts 43, cost 
centers 45, currency exchange rates 47, general ledger (G/L) 
accounts 49, PO history invoices 53, PO history receipts 55, 
and confirmations 56. The outputs from customer RCS system 
40 to procurement system 42 include requisitions 51 and 
positive confirmation responses 57. 

The inputs to customer RCW system 40 from a customer 
requester browser 46 include submit requisition, and outputs 
from system 40 to browser 46 include approval/rejection 
notice 62, status display 63, and negative/positive/INR 
END 9 2000 0175 US1 11 



confirmation. Notice and response data 65 is exchanged 
between RCW system 4 0 and browser 46. 

Other inputs to RCW system 4 0 include vendor catalogs 
73 from vendors 245-247 via enterprise EDI translator 44, 
postal code validation data 74 from an enterprise RCW system 
(not shown) , and human resource extract data 70 from 
enterprise hub server 52. RCW system 40 also provides 
approval notices 72 and receives approve/reject data 71. 
Approval Notices go to the departmental approvers for the 
person creating the requisition. These can be the 
requester's managers (first-line, second-line, etc), as well 
as chemical approvers, commodity approvers, financial 
approvers, etc. 

Referring to Figure 4, enterprise procurement system 42 
receives as inputs from customer RCW system 40 requisitions 
51 and positive confirmation responses 57, and provides to 
customer RCW system 4 0 requisition status data, purchase 
order status and contracts data 43, cost center data 45, 
currency exchange rates 47, G/L accounts 49, PO history 
invoices 53, PO history receipts 55, and confirmations 56. 



Inputs to procurement system 42 from hub server 52 
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include cost center data 79, and outputs to hub server 52 
include BDW extracts, company process control table 7 6, 
vendor master updates 77, and accounting detail 78. 

Inputs to procurement system 42 from enterprise EDI 
translator 44 include IDOC PO acknowledgment 88, IDOC 
invoices 89, IDOC payment status 92 and file transfer check 
reconstruction 93. Outputs to EDI translator include IDOC 
PO 87, IDOC invoice rejection 90 and IDOC payments 91. 

Inputs to enterprise procurement system 42 from SAP 
operator terminals include process PO's, RFQ, and contracts 
data 81, create/change vendor master data 82, invoice 
processing 8 3 (which is one input to a general procurement 
invoicing function within procurement services system 42), 
payment proposal data 84, and payment post and print 85. 
Also input to procurement system 42 is currency exchange 
rate data 80 from an external financial services server (not 
shown) via an enterprise currency exchange rates server (not 
shown) , and output from procurement system 42 to vendors 48 
are paper or fax PO documents 86. 



Referring to Figure 5, inputs to enterprise EDI 
translator 44 from procurement system 42 include IDOC PO 87 
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and IDOC invoice reject 90, and outputs to SAP system 42 
include IDOC PO acknowledge 88, IDOC invoice 89, IDOC 
payments 91, IDOC payment status 92 and file transfer check 
reconstruction 93 . 

Inputs to enterprise EDI translator 44 from vendor 48 
include PO acknowledge 95 and invoice 96, and outputs to 
vendor 48 include electronic purchase order 94 (as 
distinguished from paper or fax POs 86) and invoice reject 
97. EDI translator also receives payments 32 from source 32 
and provides payments to customer EDI translator 30. Bank 
32 provides cashed checks and payment status to EDI 
translator 44. Vendor 48 provides goods shipments 35 to 
customer receiving 34, and receives back goods returns 36. 
Vendor 48 receives paper or fax purchasing documents 37 from 
SAP 42, and provides paper invoices 38 (as distinguished 
from electronic invoices 96) to enterprise accounts payable 
for invoice processing 83 at SAP 42. 

In accordance with the preferred embodiment of the 
invention,, there is a difference between the hub server 52 
and the customer ReqCatWeb 40. Hub server 52 is where the 
confirmation notices are generated (negcons, poscons, item 
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not received (inr) ) and sent via e-mail to the requesters, 
or initiators, and the summary reports to the managers. The 
negative confirmation rejections are not handled by any of 
these systems, but by a note to a designated recipient, 
defined in a configuration file (Notes Document) , and done 
entirely via e-mail. Positive confirmations are handled at 
the user-interface level by ReqCatWeb 40, but the recording 
of the accept or reject of the positive confirmation is 
handled in hub server 52, as both ReqCatWeb 40 and and hub 
server 52 share access to the database system where all the 
confirmation data for a given purchase is stored. 

Referring to Figure 6, enterprise procurement services 
hub server 52 receives as inputs from procurement system 42 
BDW extracts 75, company process control table 7 6, vendor 
master updates 77 and accounting detail 78, and provides 
cost centers data 7 9 (which it receives from customer -ERP 
system 54.) Hub server 52 provides human resource extract 
data 70, extracted from customer employee data 60, to 
customer RCW system 40. 

Hub server 52 provides to customer ERP system 54 vendor 
master data 2 6, invoice detail 27, payment detail 28 and 
blank clearing detail data 29, and receives cost centers 
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data 25. Customer ERP system 54 also receives goods 
receipts 66 from customer receiving 34. 

Hub server 52 provides BDW extracts 58 to data 
warehouse 50. 

The operation and inter relationships of elements of 
the architecture of Figures 2-b6 pertinent to the present 
invention will be described hereafter in connection with 
preferred and exemplary embodiments of the systems and 
methods of the invention. 

Referring to Figure 7, in accordance with the preferred 
embodiment of the invention, a customer requester 
workstation is connected via a user interface 431 to a 
front-end requisition and catalog system (Req/Cat Web, or 
RCW) 40. RCW 40 is connected via interface 432 with 
procurement services system (SAP) 42. SAP 42 is in 
electronic or physical communication with vendor 48. An 
image system and store 24 is connected to scanner 23, via 
interface 437 with SAP system 42, and via interface 438 with 
workstation 438. 



In operation, the system of Figure 7 supports a process 
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for requisitioning and purchasing commodities and for 
capturing invoices and storing them for viewing on the web. 

A customer requester 46 interfaces RCW 40 to prepare an 
purchase request, which is passed as a requisition over 
interface 432 to SAP 42. SAP 42 prepares from the 
requisition a purchase order which is sent via EDI as IDOC 
PO 87 or as paper purchasing document 86 to vendor 48. 
Vendor, or supplier, 4 8 fills the order and sends back an 
invoice, either electronically as IDOC invoice 89 to SAP 42, 
or as paper invoice 38 which is received and processed by 
accounts payable personnel. As is represented by line 436 
and block 83, accounts payable personnel 22 process paper 
invoice information to SAP 42. SAP 42 posts the invoice 
back to RCW 40 which will then send an e-mail notice to user 
46 that the invoice will be paid either with (positive) or 
without (negative) confirmation. 

As invoices are received in accounts payable 22, the 
paper documents are sorted and batched, and then scanned by 
scanner 23 into scanned image file 24. This scanning may 
be done in connection with invoice processing 83 and, in 
either event, when processing the invoice to SAP 42, data is 
provided identifying the invoice image in store 24. When 
END9 2000 0175 JJS1 17 



posting the invoice to RCW 40 for conf irmation, the data 
bridged to RCW 40 by SAP 42 includes unique identifiers that 
are specific to the invoice and are pointers to the invoice 
image in store 24. 

Responsive to invoice and image data received from SAP 
42, RCW 40 prepares a confirmation notice which is sent by 
e-mail to customer 46. This notice includes url strings 
which, upon selection by requester 46, are executed to 
present the invoice images of the invoice from store 24 at 
requester workstation 46. 

: Requester 46 is also provided a search interface in RCW 
40 that allows a requester to enter criteria and have images 
of invoices that match that criteria be displayed at 
workstation 46. Similarly, this interface is available to 
accounts payable workstations 22 for the same purpose. 

There is also allowance for financial review personnel 
to view invoices based on various criteria, including by 
company or company grouping, or all invoice images. 



Invoices 89 received via electronic interchange data 
(EDI) are, preferably on a batch basis, converted into text 
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and image files that have the look and feel of paper 
invoices, and are thus user friendly, or easily understood. 
As is represented by interface 437, these invoice files are 
also sent to image system and store 24 and linked with 
corresponding invoice files in SAP 42 and viewable by 
requester 46 when processing a positive or negative 
confirmation request. 

Figures 8-12 represent a series of screen captures 
illustrating the user interface for requester processing of 
invoice confirmations. 

In Figure 8, the requester is presented with a 
confirmations panel that includes buttons or tabs for 
selecting, inter alia, a listing of current confirmation 
notices and a search of invoice images. The buttons at the 
tope allow the user to view all invoice images, search for a 
particular invoice image and to move forward or back between 
screens. 

Selecting "View All" from the screen of Figure 8 
results in a display like that of Figure 9. To search for a 
particular invoice, the user clicks on the search button and 
in response is presented a screen in which to enter search 
END 9 2000 0175 US1 19 



arguments. After entering the search arguments and clicking 
on the search button the user is presented with a screen 
like that of Figure 9, an example of a search for country 
CA, company ONCA, and invoice 310000002. Upon clicking on a 
particular invoice in the invoice images list of the screen 
of Figure 9, the user is presented with a screen, like that 
of Figure 10, showing the actual invoice that is associated 
with the selected invoice key. Figure 11 illustrates that 
various zoom and fit functions are afforded to the user to 
work with the invoice image. 

Advantages over the Prior Art 

It is an advantage of the invention that there is 
provided an improved system and method for processing 
invoices . 

It is a further advantage of the invention that there 
is provided a system and method for processing invoices 
according to either a positive or negative approval process. 

It is a further advantage of the invention that there 
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is provided a system and method for processing both 
electronic and paper invoices by either a positive or 
negative approval process and with electronic capture and 
storage of all invoices for viewing by a customer requester. 



Alternative Embodiments 

It will be appreciated that, although specific 
embodiments of the invention have been described herein for 
purposes of illustration, various modifications may be made 
without departing from the spirit and scope of the 
invention. In particular, it is within the scope of the 
invention to provide a computer program product or program 
element, or a program storage or memory device such as a 
solid or fluid transmission medium, magnetic or optical 
wire, tape or disc, or the like, for storing signals 
readable by a machine, for controlling the operation of a 
computer according to the method of the invention and/or to 
structure its components in accordance with the system of 
the invention. 
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Further, each step of the method may be executed on any 
general computer, such as an IBM System 390, AS/400, PC or 
the like and pursuant to one or more, or a part of one or 
more, program elements, modules or objects generated from 
any programming language, such as C++, Java, Java Script, 
Pl/1, Fortran or the like. And still further, each said 
step, or a file or object or the like implementing each said 
step, may be executed by special purpose hardware or a 
circuit module designed for that purpose. 

Accordingly, the scope of protection of this invention 
is limited only by the following claims and their 
equivalents. 
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